Reset Modules as an Xcode local package with tests in CI#24518
Reset Modules as an Xcode local package with tests in CI#24518
Conversation
Generated by 🚫 Danger |
|
| App Name | Jetpack | |
| Configuration | Release-Alpha | |
| Build Number | 27638 | |
| Version | PR #24518 | |
| Bundle ID | com.jetpack.alpha | |
| Commit | 35e360b | |
| Installation URL | 4ou60b6lvr0io |
|
| App Name | WordPress | |
| Configuration | Release-Alpha | |
| Build Number | 27638 | |
| Version | PR #24518 | |
| Bundle ID | org.wordpress.alpha | |
| Commit | 35e360b | |
| Installation URL | 7q8s5eep52dho |
| .testTarget(name: "WordPressFluxTests", dependencies: ["WordPressFlux"], swiftSettings: [.swiftLanguageMode(.v5)]), | ||
| .testTarget( | ||
| name: "WordPressFluxTests", | ||
| dependencies: ["WordPressFlux"], | ||
| exclude: ["WordPressFluxTests.xctestplan"], | ||
| swiftSettings: [.swiftLanguageMode(.v5)] | ||
| ), |
There was a problem hiding this comment.
I added this to see how WordPressFluxTests would run tests with standalone scheme.
Interestingly, I tried using a copy-paste friendly exclude: ["*.xctestplan"], pattern, but it failed to find the file.
| relativePath = ../Modules; | ||
| }; | ||
| /* End XCLocalSwiftPackageReference section */ | ||
|
|
There was a problem hiding this comment.
I think the difference between this and the previous setup (pre #24511) is that we no longer have any local swift package reference as a dependency for WordPress.
My guess is that, whichever way it ended up like that, the duplicated reference—as a local module in the workspace and as a package reference—is what resulted in the duplicated entries shown in the #24511 description.
kean
left a comment
There was a problem hiding this comment.
This looks good. Let's switch back to the standard "drag-n-drop" approach. I left a couple of small comments.
Modules/Package.swift
Outdated
| name: "Modules", | ||
| platforms: [ | ||
| .iOS(.v16), | ||
| .macOS(.v14), // Here just to avoid errors when building directly with `swift build` |
There was a problem hiding this comment.
Is this addition necessary? Most of our packages do not support macOS and won't compile with it as a target.
There was a problem hiding this comment.
I find it handy to have just so swift build throws legitimate errors with the code rather than with the versions.
In particular, it was necessary to run the WordPressFlux tests via swift test. However, as I try to reproduce, I can't get past some UIKit errors, which I find odd when focused on WordPressFlux, but don't have bandwidth to investigate.
Removed it.
There was a problem hiding this comment.
Thanks! Yeah, I'd remove it since it doesn't support macOS.
| <?xml version="1.0" encoding="UTF-8"?> | ||
| <Workspace | ||
| version = "1.0"> | ||
| <FileRef |
There was a problem hiding this comment.
Let's add Modules to a project and not a workspace. We we going to remove the workspace.
There was a problem hiding this comment.
We we going to remove the workspace.
I started looking at it #24534
76d9467 to
8e08ab4
Compare
| # | ||
| # Ignore the Package.resolved file. The packages source of truth is the | ||
| # resolved file generated by the Xcode workspace. | ||
| Modules/Package.resolved |
There was a problem hiding this comment.
I thought you had to use ...ace/xcshareddata/swiftpm/Package.resolved managed by Xcode? Modules/Package.resolved isn't, or is it? How did you get it to work? When you open the Xcode project, does it use pins from Modules/Package.resolved?
...ace/xcshareddata/swiftpm/Package.resolved → Modules/Package.resolved
There was a problem hiding this comment.
Apologies @kean this change surprised me a bit and I should have preempted your question writing about it.
Before
Modules was part of the workspace. When Xcode detected changes in Modules/Package.swift, it triggered the packages resolution and updated the resolved file in the workspace xcshareddata folder.
After
Modules is part of the project, but is not a dependency of the project:
When Xcode detects a change in Modules/Package.swift, it triggers the packages resolution and updates Modules/Package.resolved.
I guess that if we were to add additional package dependencies to the project Xcode would then re-introduce the workspace resolved file.
There was a problem hiding this comment.
When Xcode detects a change in Modules/Package.swift, it triggers the packages resolution and updates Modules/Package.resolved.
I verified this by switching color-studio from pointing to a branch to a commit. The screenshot below shows Xcode highlighting the change in the gutter and the package resolution running.
35e360b tracks the changes and the .resolved update.
Given OCLint is something we should drop soon, because it's only for Objective-C and we want to reduce that code surface.
Locking dependencies to commits makes updating them a bit more burdensome, but at least it makes the update intentional and not automatic and surprising. This change was done to test Xcode's behavior in monitoring `Modules/Package.swift` and updating `Modules/Package.resolved`. See #24518 (comment)
8e08ab4 to
35e360b
Compare
|








Description
#24511 successfully addressed the issue of duplicated packages in the target selection.
Unfortunately, it resulted in all local packages (those from
Modules/that is) no longer being accessible to the unit tests runner—see internal discussion in p1746169066574499/1745343713.430699-slack-C08HQR4C2TSThis PR propose a different fix, achieved by re-adding
Modules/as a local package not a package dependency, following the instructions from https://developer.apple.com/documentation/xcode/organizing-your-code-with-local-packages.This setup maintains the single result in the target search...
...while also allowing for
Modules/to run as dedicated schemes or as part of a test planAlso notice, we have so many tests (and warnings when running them!) that the logs don't show the first tests that run, but if you check the XML report, you'll see that indeed we are running all previously disabled tests
Next steps
WordPressUnitTests.xctestplantoKeystone.xctestplan—to do in dedicated PR to avoid diff noise hereKeystone.xctestplanhttps://linear.app/a8c/issue/AINFRA-428/investigate-wjr-setup-that-addresses-duplicated-modules-while